%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Iteration 1
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Iteration 1: SAB (M2)}
\label{sec:iteration_1}

In this first iteration we decompose the SAB system. The main architectural driver is QaS M2: "Disaster and attack recovery". This requirement has an influence on all upcoming architectural decisions and sets the tone for a distributed design.
While we take M2 into account in all following decisions, it can be noted that M2 focuses mainly on the availability of transaction processing and account data. Based on this we can make a first decomposition.


Relevant use cases to this decomposition are:
\begin{itemize}
    \item UC11: Execute transaction.

    \item UC4: Select customer.

    \item UC5: Consult bank account overview.

    \item UC6: Consult transaction history of account.

    \item UC17: Read Messages.
\end{itemize}
These use cases are relevant because no ongoing transactions, past transactions and messages can be lost and account data and account balances need to remain intact.


The driver can be summarized in the following requirements:
\begin{itemize}
    \item M2 has to do with being able to geographically scale the system in the future.

    \item In the future, when a geographical site goes down, performance should only be minimally affected.

    \item There should be no single point of failure in the future. Downtime is permitted.

    \item In the future, no ongoing or past transactions should be lost in case of a disaster or attack.

    \item In the future, no account data is lost in case of a disaster or attack.

    \item In the future, all account balances remain intact in case of a disaster or attack.
\end{itemize}




To satisfy these drivers we considered different modifiability tactics to find an appropriate solution.
\begin{description}

    \item[Localize Modifications] \hfill \\
    
        \vspace{-5mm} 
        \begin{description}

            \item[Maintain semantic coherence:] Different functionalities are encapsulated in separate components that can run in their own environment.
            
            \item[Anticipate expected changes:] All decompositions are made with scalability and redundancy in mind.
            
            \item[Limit possible options:] Decompositions are shown in component diagrams which illustrate the border and interfaces of encapsulated processes. The deployment diagram further groups these components by hardware.
            
            
        \end{description}	

        
    \item[Prevent ripple effects:] \hfill \\
    
        \vspace{-5mm} 
        \begin{description}

            \item[Hide information:] Information hiding by isolating specific interfaces helps to prevent ripple effects by enabling modular design.
            
            \item[Use an intermediary:] An intermediary can be used to encapsulate and group specific functionalities. This way ripple effects can be prevented. 
            
            
        \end{description}
    
    \item[Defer binding time:] The system enables hardware scaling to improve performance and robustness. Geographically distributed solutions are preferred. \hfill \\
    
	\vspace{-5mm} 
        \begin{description}
	    \item[Runtime registration:] The distributed design requires interacting components to register with each other, requiring publisher/subscriber-like patterns. The components can run on separate computers and can communicate even over a wide area network.
            
            \item[Component replacement:] New components can be added easily through runtime registration.
        \end{description}

        
\end{description}

    
Usually hardware scaling is not the preferred solution because of the cost. However, for this quality attribute scenario we require support for geographical redundancy so hardware scaling and distributed design are imperative. All possible benefits resulting from this tactic should be used to their full extent. This solution is difficult to apply by itself, rather it is something to keep in mind during the whole ADD process.



\begin{figure}[!ht]
    \centering
        \includegraphics[width=1.0\textwidth]{images/It1_M2_componentdiag.png}
    \caption{Component diagram after iteration 1.}
    \label{fig:It1_M2_componentdiag}
\end{figure}



The result of the first decomposition can be viewed in figure \ref{fig:It1_M2_componentdiag}. This decomposition was made to maintain semantic coherence and to anticipate expected changes where the \emph{Transaction Processing System}, \emph{Transaction Database}, \emph{Balance Database} and \emph{Account Database} encapsulate different functionalities and can be replicated to different geographical locations in the future. To encapsulate certain information and hide unnecessary functionalities we will provide the \emph{Send Notification}, \emph{Customer Information} and \emph{TPS Access} components that implement the Facade pattern.

Here the \emph{Transaction Processing System} (TPS) will be responsible for processing all incoming transactions and send out resulting replies. This \emph{Transaction Processing System} needs to write processed transactions to the \emph{Transaction Database} and needs to access the \emph{Balance Database} in order to correctly process these transactions. These accesses are provided by the \emph{TPS Facade}. The \emph{Transaction Processing System} also needs to communicate with the not yet decomposed \emph{Rest of System} to receive incoming transaction commands that need to be processed and to send out the necessary replies. Notifications of failed transactions are send to the \emph{Notification Inbox} through the \emph{Send Notification} facade.

The \emph{Transaction Database} component will be responsible for holding the full history of processed transactions. This history needs to be read by the \emph{Rest of System} to support UC6: Consult transaction history of account. This read-functionality is encapsulated by the \emph{Customer information} facade.

The \emph{Balance Database} component will be responsible for holding the account balances of all SAB bank accounts, and provides correct access to the \emph{Transaction Processing System} and the rest of the system. The \emph{Balance Database} will need to be read and modified by the \emph{Transaction Processing System} through the \emph{TPS Facade} in order to correctly process transaction commands. The \emph{Balance Database} will also need to be read by \emph{Rest of System} in order to provide the functionality for UC5: Consult bank account overview. This read-functionality is encapsulated by the \emph{Customer information} facade.

The \emph{Notification Inbox} component will be responsible for holding all notification messages directed to the customer. Messages can be sent with the \emph{Send Notification} facade. The \emph{Notification Inbox} will need to be accessed by \emph{Rest of System} in order to provide the functionality for UC17: Read Messages. This read-functionality is encapsulated by the \emph{Customer information} facade.

The \emph{Account Database} will be responsible for storing customer information that does not need to be accessed by the \emph{Transaction Processing System} (e.g. the customer's name, address, passport number...). The \emph{Rest of System} will need to access this \emph{Account Database} in order to provide the functionality for UC4: Select customer. This read-functionality is encapsulated by the \emph{Customer information} facade.

The requirements can be divided over the decomposition as noted below. Note that M2 is divided over all these components because we wanted to anticipate expected changes in this iteration by preventing ripple effects.
\begin{itemize}
 
    \item \emph{Transaction Processing System}
    \begin{itemize}   
        \item P1: ATM and POS around Christmas
        \item P3: Transaction processing
        \item M2: Disaster and attack recovery
		\item UC7: Deposit cash
        \item UC8: Withdraw cash
        \item UC9: Issue transfer between two accounts
        \item UC11: Execute transaction
        \item UC13: Issue payment with bank card
        \item UC15: Execute direct debit
        \item UC21: Pay interests
        \item UC23: Send interbank credit instruction
        \item UC24: Receive status update for interbank credit instruction
        \item UC25: Process interbank credit instruction       
    \end{itemize}


    \item  \emph{Transaction Database}
    \begin{itemize}
        \item Av3: Transaction database failure
        \item M2: Disaster and attack recovery
        \item UC6: Consult transaction history of account
    \end{itemize}
    
    
    \item  \emph{Balance Database}
    \begin{itemize}
    		\item M2: Disaster and attack recovery
        \item UC5: Consult bank account overview
    \end{itemize}
    
    
    \item  \emph{Account Database}
    \begin{itemize}
    		\item M2: Disaster and attack recovery
        \item UC3: Register new customer
        \item UC4: Select customer
    \end{itemize}
    
    \item  \emph{Notification Inbox}
    \begin{itemize}
        \item M2: Disaster and attack recovery
        \item UC17: Read messages
    \end{itemize}
    
    
    \item  \emph{Customer Information}
    \begin{itemize}
        \item M2: Disaster and attack recovery
        \item UC4: Select customer
        \item UC5: Consult bank account overview
        \item UC6: Consult transaction history of account
    \end{itemize}
    
    
    \item  \emph{Send Notification}
    \begin{itemize}
        \item M2: Disaster and attack recovery
        \item UC11: Execute transaction
    \end{itemize}
    
    
    \item  \emph{TPS Facade}
    \begin{itemize}
        \item M2: Disaster and attack recovery
    \end{itemize}
    
    
    
    \item  \emph{Rest of System}
    \begin{itemize}
        \item Av1: Interbank communication failure
        \item Av2: SAB Online
        \item P2: Processing credit instructions and/or credit instruction status updates from other banks
        \item M1: SAB Mobile
        \item M2: Disaster and attack recovery
        \item M3: Debt and credit cards
        \item UC1: Log in
        \item UC2: Log off
        \item UC3: Register new customer
        \item UC7: Deposit cash
        \item UC8: Withdraw cash
        \item UC10: Set up standing order
        \item UC12: Cancel standing order
        \item UC13: Issue payment with bank card
        \item UC14: Set up authorization for direct debit
        \item UC15: Execute direct debit
        \item UC16: Retract authorisation for direct debit
        \item UC18: Block bank card
        \item UC19: Initiate fraud detection
        \item UC20: Send results for fraud detection
        \item UC21: Pay interests
        \item UC22: Update interest rate
        \item UC23: Send interbank credit instruction
        \item UC24: Receive status update for interbank credit instruction
        \item UC25: Process interbank credit instruction 
    \end{itemize}
\end{itemize}   
